The IEEE Verilog 1364-2001 Standard; What's New and Why You Need It

At the time of this conference, the proposed IEEE 13642000 Verilog standard is complete, and in the balloting process for final IEEE approval [update: official IEEE ratification was not completed until March 2001, making the official name IEEE 1364-2001, and the nickname Verilog-2001]. Verilog-2001 adds many significant enhancements to the Verilog language, which add greater support for configurable IP modeling, deep-submicron accuracy, and design management. Other enhancements make Verilog easier to use. These changes will affect everyone who uses the Verilog language, as well as those who implement Verilog software tools. This paper presents a summary of several of the enhancements in Verilog-2001. 1. History of the IEEE 1364 Verilog standard The Verilog Hardware Description Language was first introduced in 1984, as a proprietary language from Gateway Design Automation. The original Verilog language was designed to be used with a single product, the Gateway Verilog-XL digital logic simulator. In 1989, Gateway Design Automation was acquired by Cadence Design Systems. In 1990, Cadence released the Verilog Hardware Description Language and the Verilog Programming Language Interface (PLI) to the public domain. Open Verilog International (OVI) was formed to control the public domain Verilog, and to promote its usage. Cadence turned over to OVI the FrameMaker source files of the Cadence Verilog-XL user’s manual. This document became OVI’s Verilog 1.0 Reference Manual. In 1993, OVI released its Verilog 2.0 Reference Manual, which contained a few enhancements to the Verilog language, such as array of instances. OVI then submitted a request to the IEEE to formally standardize Verilog 2.0. The IEEE formed a standards working group to create the standard, and, in 1995, IEEE 1364-1995 became the official Verilog standard. It is important to note that for Verilog-1995, the IEEE standards working group did not consider any enhancements to the Verilog language. The goal was to standardize the Verilog language the way it was being used at that time. The IEEE working group also decided not to create an entirely new document for the IEEE 1364 standard. Instead, the OVI FrameMaker files were used to create the IEEE standard. Since the origin of the OVI manual was a user’s manual, the IEEE 1364-1995 and IEEE 1364-2001 Verilog language reference manuals [1][2] are still organized somewhat like a user’s guide. 2. Goals for IEEE 1364-2001 Verilog standard Work on the IEEE 1364-2001 Verilog standard began in January 1997. Three major goals were established: • Enhance the Verilog language to help with today’s deep submicron and intellectual property modeling issues. • Ensure that all enhancements were both useful and practical, and that simulator and synthesis vendors would implement Verilog-2001 in their products. • Correct any errata or ambiguities in the IEEE 1364-1995 Verilog Language Reference Manual. The Verilog-2001 standard working group was comprised of about 20 participants, representing a diversified mix of Verilog users, simulation vendors and synthesis vendors. The working group was divided into three task forces: The ASIC Task Force developed enhancements to meet the needs of very deep submicron timing accuracy. The Behavioral Task Force developed enhancements for Behavioral and RTL modeling. The PLI Task Force enhanced the Verilog Programming Language Interface to support changes from the other task forces, as well as adding new capabilities to the PLI. 3. Modeling enhancements The 21 enhancements listed in this section give Verilog designers more capability for creating Verilog models. Many enhancements improve the ease and accuracy of writing synthesizable RTL models. Other enhancements allow models to be more scalable and re-usable. Only changes which add new functionality or syntax are listed here. Clarifications to Verilog-1995 are not listed. This paper was first presented at the 9th Annual International HDL Conference and Exhibition, March 2000, Santa Clara, CA.. Minor updates and clarifications were made by the author in October, 2001. Copyright 2000, Sutherland HDL, Inc., Tualatin, Oregon. © 2000, Sutherland HDL, Inc. page 2 of 8 3.1 Design management—Verilog configurations The Verilog-1995 standard leaves design management to software tools, rather than making it part of the language. Each simulator vendor has devised ways to handle different versions of Verilog models, but these tool-specific methods are not portable across all Verilog software tools. Verilog-2001 adds configuration blocks, which allow the exact version and source location of each Verilog module to be specified as part of the Verilog language. For portability, virtual model libraries are used in configuration blocks, and separate library map files associate virtual libraries with physical locations. Configuration blocks are specified outside of module definitions. The names of configurations exist in the same name space as module names and primitive names. New keywords config and endconfig are reserved in Verilog-2001. Additional keywords are reserved for use within a configuration block: design, instance, cell, use and liblist. The full syntax and usage of Verilog configuration blocks is beyond the scope of this paper. The following example illustrates a simple design configuration. The Verilog source code is typical; a test bench module contains an instance of the top-level of a design hierarchy, and the top level of the design includes instances of other modules. module test; ... myChip dut (...); /* instance of design */ ... endmodule module myChip(...); ... adder a1 (...); adder a2 (...); ... endmodule The configuration block specifies the source code location of all, or specific, module instances. Because the configuration is specified outside of Verilog modules, the Verilog model source code does not need to be modified to reconfigure a design. In this configuration example, instance a1 of the adder will be compiled from the RTL library, and instance a2 from a specific gate-level library. /* define a name for this configuration */ config cfg4 /* specify where to find top level modules */ design rtlLib.top /* set the default search order for finding instantiated modules */ default liblist rtlLib gateLib; /* explicitly specify which library to use for the following module instance */ instance test.dut.a2 liblist gateLib; endconfig The configuration block uses virtual libraries to specify the location of the Verilog model sources. A library map file is used to associate the virtual library names with physical file locations. For example: /* location of RTL models (current directory) */ library rtlLib ./*.v; /* Location of synthesized models */ library gateLib ./synth_out/*.v; 3.2 Scalable models—Verilog generate The Verilog-1995 standard has limitations on defining Verilog models that are scalable and easy to re-use in other designs. Verilog-1995 has the array of instances construct, which, though powerful, does not provide the flexibility needed for truly scalable, complex design structures. Verilog-2001 adds generate loops, which permit generating multiple instances of modules and primitives, as well as generating multiple occurrences of variables, nets, tasks, functions, continuous assignments, initial procedures, and always procedures. Generated declarations and instantiations can be conditionally created, using if– else decisions and case statements. Four new keywords have been added in Verilog-2001: generate, endgenerate, genvar and localparam. The genvar keyword is a new data type, which stores positive integer values. It differs from other Verilog variables in that it can be assigned values and changed during compile or elaboration time. The index variable used in a generate loop must be declared as a genvar. A localparam is a constant that is similar to a parameter, but which cannot be directly changed using parameter redefinition. A generate block can also use certain Verilog programming statements to control what objects are generated. These are: for loops, if–else decisions and case decisions. The following example illustrates using generate to create scalable module instances for a multiplier. If either of the multiplier’s a_width or b_width parameters are less than 8, a CLA multiplier is instantiated. If a_width and b_width are 8 bits or more, a Wallace tree multiplier is instantiated. module multiplier (a, b, product); parameter a_width = 8, b_width = 8; localparam product_width = a_width+b_width; input [a_width-1:0] a; input [b_width-1:0] b; output[product_width-1:0]product; generate if((a_width < 8) || (b_width < 8)) CLA_multiplier #(a_width, b_width) u1 (a, b, product); else WALLACE_multiplier #(a_width, b_width) u1 (a, b, product); endgenerate endmodule